The Debian Description Translation Project is a very old project which had many adventures in the past. Indeed, working on packages descriptions translations has been my very first work in Debian l10n back in....long ago. Unfortunately, because of the servers compromise and also because of the lack of support for translated descriptions in the archive and package tools such as APT, the project slowly lost interest from translators. The revival may be dated back in 2005 when Michael Bramer revived the project and even more in 2006 when experimental support was added in APT as well as some support in the archive. While the framework is still quite crude (no offense intended for grisu who did a great job maintaining it) and not very opened to collaborative work and peer review, a few teams did a great job translating the zillions of package descriptions. And we still expect to use Pootle soon. So, as we now have a big enough handicap, it's time for the French team to beat them all in the friendly competitions we all enjoy..:-). For that reason, I began to translate dozens of packages descriptions last week and a few other French translators joined me. I somewhat expect us to slowly put all of our (wo)manpower in this and, therefore, translate as many packages descriptions as possible. The count begins with 1896 active translations, French being ranked 5th after German, Japanese, Czech and Brazilian Portuguese, even with Korean. So, the next target is the Brazilian team. Watch out your back, fellows..:-)

While Subversion is for many the source code revision system of choice, I've never stopped long with it myself. Why? Because it's mostly a fixed-up CVS, and doesn't fix the really gnarly problem with revision control: merging.Mark Shuttleworth has written an insightful little article on the key aspects of merging source code. Some of the points he makes underpin my choice of revision control system.For several years now I've been a very contented user of Bazaar, in its first arch-based incarnation, and now in its latter form. The key reason has been ease of merging.While most articles praising Bazaar are reports of open source development, I've also found it very handy for small in-house teams working on web applications.There are very often multiple arcs of development going on at once, and the ease of merging makes it easy to ensure that long-running development arcs don't get ridiculously far from the main trunk of development. Bazaar's merging also makes it easier for lead developers to police the merging of the code base.Using Bazaar with Rails and other toolsWorking mostly with Rails, one repeatedly runs up against the assumption that Subversion is the golden path for revision control. This is perhaps a little telling about the level of participation most Rails-based projects have reached.The tools story for a Bazaar user is both good and bad.The good

• Deployment: the Capistrano deployment system has support for Bazaar. I've written previously about the technique I use to deploy my Rails apps.
  
• Collaboration: Trac is a wonderful integrated bug database, wiki and source code browser. Although it's a little hard to find, the trac-bzr integration works very well, and happily moves Trac out of the Subversion-based assumption that you can only have one repository root per project.
  

The bad

• Continuous integration: with Expectnation, we've had to roll our own continuous integration system ('system' being rather a grand word for a shell script on a cronjob...) Most of the CI systems currently popular seem to assume Subversion.
• Editor/IDE integration: some early work exists, but it's early days. I've not yet found anything making me want to leave the command line.
  

Figures About SVN-Maintained Packages For fun and profit I and gares have just harvested a bit alioth to discover how many packages are currently maintained using subversion. The overall result is larger than I expected 3492 source packages (to be compared with 11786 total packages in unstable) are maintained using Subversion. The numbers might be a bit approximated, I report what we did to extract these number for review. The number of subversion-ed source packages have been computed running on alioth the script harvest source fields.sh (which in turn uses svnlook grep.py) its stdout can be redirected to a .txt file. Once sorted and removed of duplicates you will get something like source pkgs on svn.txt; its length approximates the number of source packages maintained via svn:

$ wc -l source_pkgs_on_svn.txt
3493

The approximation is due to the fact that debian/control are looked for everywhere in a repository, hence it can find old packages no longer in the archive or never uploaded, and some fake package (like "MODULE NAME", but it seems to be the only one). The amount of packages which are in the above list but not in the archive is about 900 packages. Still I don't think it would be fair to exclude all of them since I guess a non trivial part of that are packages that haven't yet uploaded and hence are arguably part of the active development of Debian. Excluding them, the percentage of unstable maintained using SVN on alioth is about 22%. To that you should add the packages maintained using other version control systems. The total number of source packages in unstable have been computed on my laptop as follows:

$ cd /var/lib/apt/lists/
$ ls *Sources
ftp.it.debian.org_debian_dists_unstable_contrib_source_Sources
ftp.it.debian.org_debian_dists_unstable_main_source_Sources
ftp.it.debian.org_debian_dists_unstable_non-free_source_Sources
security.debian.org_dists_testing_updates_contrib_source_Sources
security.debian.org_dists_testing_updates_main_source_Sources
$ cat *Sources   grep ^Package:   sort -u   wc -l
11786

The broader goal was to discover how many packages are maintained using any versioning system on alioth, but we were fluent only in svn internals. Dear lazyweb, feel free to harvest and forward to me your data for the other versioning systems available on alioth, I'll keep this post updated with news.

After the feedback related to my latest post about NaughtySVN I thought it would be nice to commit my pending changes about update, although they are not enough to make a functional update feature.

I also thought is time to clarify a few things about the project:

• NaughtySVN is a project that tries to be first a sane SVN client for Nautilus in the style of TortoiseSVN available on Windows
• the project is designed in such a way that different frontends and backends can be added[1], so it shouldn't be hard (in theory) to add support for konqueror, gnome-commander on one side or darcs, mercurial or git on another side.
• For now we are working for a Nautilus+SVN client combination and we are in the alpha stage
• different menu items will appear as needed and when they make sense (the update command will appear only if an update is possible, i.e. context menu of a file/directory in a working copy)

[1] see the comment starting from "A word of caution" in this message from Alexander Thomas

... is NaughtySVN.

I have joined this project which was started by Alexander Thomas a few weeks ago and I have convinced him that is better to have a release sooner rather than later. The project is still in its early alpha stage[*] but I thought is better to have a rather minimalist and functional client first.
So, I talked to Alexander and we came up with a roadmap; for the 0.0.1 release I am working on the update feature which is about 40% done[1][2] (update dialog screenshot).

Of course, after the release I will probably make a debian package, too, unless someone else beats me to it :-) .

So, the future is bright.


Update: as a response to a comment, NaughtySVN is designed to be not only a Subversion client, but also a framework for other VCS-es and other clients. It just happens that we are working on the Subversion backend and client at the moment.

P.S.: as curiosity of mine, I have written in python a small nautilus plugin that does the svn update (is a svn frontend) and I must say I really miss the development speed of python when writing in C (or maybe I am out of practice).

[*] only a few features are implemented and can't be used yet as a SVN client without being forced to use another client.
[1] according to my estimations
[2] update related code is not committed yet

It’s been a crazy few weeks. I’ve heard the phrase “drinking from the fire hose” many times, and while I’ve never actually tried to do that, I suspect the experience is something like this. I’m having a blast though. A few quick first impressions:

1. First things first: The lead up to the announcement was remarkable—not at all what I expected from a big company. As Jim Grisanzio pointed out, the PR people did a great job coordinating everything, but the bloggers were very much in the lead here. In fact, I was given so little (OK, no) guidance on what “the message” was supposed to be that I sent a draft of what I was going to post to Jonathan, and he replied, no one is allowed to run their posts by me, just speak your mind, that’s what we all do. The message: Sun really is as transparent as it appears from the outside perspective.
2. In the other direction, the people here are not only open to the outside perspective, they want to hear it. That’s a big part of the reason I’m here now. Solaris has lost a lot of developer mindshare to Linux over the past 5-10 years. There are important lessons to be learned from that, and we (yes, I feel like it’s “we” already) are intent on doing just that.
3. Maybe it’s just the people I’m working with, but this place feels like a startup. There’s a lot of positive energy, a real sense of urgency, and people genuinely seem to love what they’re doing. The difference: It’s a startup with actual resources. You know, like 30,000+ people. A potent combination indeed.

Regular blogging should resume shortly.

Based on Bart Trojanowski’s blog article “etc snapshots with git” I removed one further item from my todo list: maintain /etc with mercurial on my Debian systems. First step is creating the repository and securing access to the repository. As mercurial stores all its files within one single directory named .hg you won’t have any further directories within /etc besides /etc/.hg, rocking - right?

cd /etc
hg init
chmod og-rwx .hg

Ignore a few files:

cat > .hgignore << EOF
syntax: regexp
(^)*.dpkg-new
(^)*.dpkg-old
(^)blkid.tab( .old)
(^)mtab
# add other files if necessary, depends on your setup...
EOF

Now commit the current state:

hg add
hg ci -m "initial checkin"

We want to commit the changes automatically when using apt-get/aptitude so let’s write and include a wrapper for it:

cat > /etc/apt/hg-snapshot-script << EOF
#!/bin/sh
set -e
caller=$(ps axww   mawk '/aptitude apt-get/  for (i=5; i<=NF ; i++) printf ("%s ",$i); printf ("n")  '   head -1)
hg add 1>/dev/null
STATUS="$(hg st)"
if [ -n "$STATUS" ] ; then
   echo "hg-snapshot-script: found changed files:"
   hg st
   hg ci -m "snapshot from $LOGNAME after: $caller"
else
   echo "hg-snapshot-script: nothing to be done"
fi
EOF
chmod +x /etc/apt/hg-snapshot-script
cat >> /etc/apt/apt.conf << EOF
DPkg  
  Post-Invoke  "cd /etc ; ./apt/hg-snapshot-script"; ;
 
EOF

Finally track the two files too:

hg add
hg commit -m "apt will track /etc automagically using hg"

That’s it. Oh BTW: users of subversion might want to point their browser to /etc under svk (by Enrico Zini).

Experiences with a Trac Server In the last few days after Xmas I set up http://trac.cs.unibo.it, a server for my CS department which will host a bunch of Trac instances, initially for academic projects only then it will be opened to student projects as well. The server set-up has been "powered-by" the following technologies:

1. Debian Etch
2. Apache 2.2 with FastCGI, SuExec, and WebDAV over TLS (for accessing SVN repositories without forcibly passing through Trac)
3. Trac instances backed by Sqlite databases and Subversion repositories
4. Some bits of Genshi templating for generating the projects index
5. Some shell scripts for automating creation and removal of projects

I'm quite happy with the result. From the overall experience I drew some observations though:

• installing Etch is more a dream than ever, in 15 minutes I re-installed the server (which previously was running Ubuntu) with a decent partitioning scheme and all that I needed to work remotely. The sysadm of the department saw me coming out from the server room and asked, unbelievingly, did you already finish?
• apache2.2 in Debian is now annoyingly missing the nice script for creating easily TLS certificates (i.e. apache2-ssl-certificate). I followed-up on #395823 attaching the same script took from Sarge and the needed configuration file. Worked for me
• SuExec is stupid. You have to put stuff under /var/www for it to work at all, the only way to change the path is rebuild apache .... or, you can mount --bind /srv/trac /var/www/trac!
• BTW I like /srv. According to the FHS it's the place where I want to put my Trac projects. Unfortunately the Debian installer neglects that path and per default you end up with a system where /srv is in the same partition as /, and hence with basically no free space. Hence I also bind-mounted /srv/trac from /home/trac
• In Etch we have no available implementation of FastCGI (which really improves Trac performances BTW). libapache2-mod-fastcgi is non-free and for some reason it was not autobuild everywhere and hence is missing from testing. I pinged aba on IRC about that, so the package should probably enter testing again in a few days. Go RMs!

Happy new year birthday trac.cs.unibo.it.

There have been quite some comments on the Iceweasel case all over the planets, and I saw several assertions, especially from the Mozilla camp, that I, as the Firefox co-maintainer, the xulrunner maintainer, and (soon) Seamonkey iceape co-maintainer, have to rectify. They broke the –enable-official-branding flag
Half-true. We just replaced Bon Echo/Deer Park with Firefox at the appropriate places in the build tree so that we could have Firefox with the “unbranded” logo instead of the official logo, as Gervase Markham gave us authorization for. You’re still free to enable the official branding, except that since the logos and stuff are non-free, we removed the other-licenses/branding/ directory from the original tarball, thus yes, the flag is half broken. Firefox logos being subject to trademarks, Debian thinks they are not free.
Trademark and copyright are different things. Mozilla has unnecessarily given a non-free license to “clarify” the trademark situation, but that is not required. To make it clear: Debian thinks the logos are not free because they are not free. Period. Debian isn t properly collaborating with Mozilla , sending unusable 100000-lines patches for validation just before releases (as seen on Lucas Nussbaum’s blog)
Let me take the firefox_2.0~rc1+dfsg-1.diff.gz file, strip the debian directory from it (it only contains maintainer scripts, our set of icons and some debian specific searchplugins), and strip the configure diff that is generated by autoconf due to some changes in configure.in… that’s exactly 2654 lines of diff. Very far from the 100000-lines patches they are claiming. The Mozilla people talked about Debian-specific changes that changed frozen APIs, breaking extensions (from Lucas’s blog again).
So, let’s dig into our firefox_2.0~rc1+dfsg-1.diff.gz:

• Changes to disable application upgrade (we want that to happen through apt-get) and change some other default preferences,
• Changes to fix “make distclean” so that it really cleans the build directory,
• Change not to build the “mangle” utility,
• Change not to call netstat to generate entropy, which is useless on linux,
• Changes to make Firefox build and work on architectures such as hppa, mips, mips64, m68k, ia64, sparc64, alpha, and arm, which the Mozilla guys don’t seem to care much for,
• Change to add a preference directory so that users can put their set of customized preferences in /etc/firefox/pref,
• Change to allow to build flat chrome without the zip utility,
• Change to allow to use system library for myspell, instead of statically linking the bundled one,
• Changes to allow to build s390 binaries on s390x host with s390 toolchain (same applies with x86 binaries on amd64 host with x86 toolchain),
• Changes to work around bugs with the hidden visibility pragma on gcc,
• Changes to make the pango backend actually build correctly,
• Changes to avoid some error messages while trying to create Makefiles from inexistant Makefile.in’s,
• Change to install in /usr/lib/firefox instead of /usr/lib/firefox-x.y,
• Change not to build useless chromelist.txt files,
• Changes to make helper applications with parameters work,
• Changes to allow builds against GTK 2.8,
• Changes to work around an Xrender bug,
• Changes to make the Gecko/yymmdddd string taken from preferences instead of being half-hard-coded (you could change it with preferences, but it would still be set to the hard-coded value at start time ; and you could change it again with preferences…),
• Change to allow mice extra buttons to act as something else than a left button,
• Change to allow to build with -Wl,–as-needed to avoid linking against a whole lot of useless libraries, without losing the link on libxpcom.so which is required by some extensions’ components,
• Changes not to shlibsign the NSS modules at build time, since we’re stripping the binaries afterwards, thus breaking the signature. We do build the signatures later, within the maintainer scripts.

That’s not that many changes, and most of them were taken from either some Mozilla CVS trunk or the Mozilla Bugzilla . And most of those that were not taken from there have been sent, except those that really don’t make much sense outside Debian. So, where are these frozen API changes ? And we’re not properly collaborating, huh ? The Mozilla project started by coming to a (admittedly uneasy) agreement with Debian for use of the name, but the Debian version diverged even further from the official version, so the permission was revoked. (from comments on Matthew Garrett’s blog) That one is really interesting, because between the time we got this understanding with Gervase and now, we are actually less diverging from the official version than by then. The main difference by that time was the extensions manager, which, in Debian, needed a lot of changes to actually act as it should, especially with globally installed extensions. I’m not saying the Debian one was perfect, it also had its own problems, but that was a whole lot less than the blatant crap that was the official one, obviously written for Windows without any thoughts for unix, and especially linux distributions. The only main difference now, between the official Firefox and ours, is that our build has the pango backend enabled, which we chose over the Xft backend for several reasons I won’t explain here. The others differences are that we use system libraries where possible, instead of the bundled libpng, libjpeg, libtiff, libmyspell and libcairo. We also build a flat chrome, instead of having everything in .jar files. Now, a little bit about differences the Mozilla guys don’t seem to care about while they really should: distributions build the Mozilla products with gcc 4.x, while the official binaries are built with gcc 3.4, as well as the extensions distributed on addons.mozilla.org. Fortunately, not a lot of extensions make use of binary components, and not a lot are linked against the standard C++ library, but when that happens (like with colorzilla), you get a component linked against libstdc++5 to load on a Firefox that is linked against libstdc++6. You are lucky if that setup doesn’t crash. Little extra from comments in Lucas’s blog:
Is it possible for the Debian Firefox maintainers to create an installer package for contrib which will install the vanilla FireFox from Mozilla s site.
How great would it be to have a package for one architecture instead of 12, and with a dependency on libstdc++5, that almost no other package uses any more. Update:
Debian is going to replace Firefox with a GNU fork called Iceweasel
Half-true. For the etch release, Iceweasel will only be Firefox with a different branding. We are taking the Iceweasel name because it was already know as a possible alternative name for Firefox when the trademark concerns have been raised more than 2 years ago (thanks Nathanael Nerode for this nice name, by the way). It appears that the GNU guys decided to start a fork with this name… that’s quite unfortunate, actually. Anyways, the plan is to get in touch with them to see what we can do together, but with the etch release approaching, we can’t and won’t do more than a rename for the moment. Update 2:
We (Mozilla ) presently have working relationships with most of the major Linux distributions, including Red Hat, Novell, and Ubuntu (As seen in several posts from people of the Mozilla Corporation or Foundation)
Very interesting. Ubuntu uses the same set of patches as Debian, with some more of their own, and even releases beta software in their official releases. But when it’s Ubuntu, it’s fine. Sorry, I forgot Debian is lame, and DDs are frustrated fanatic integrists, on top of being bloody fanatic assholes. Update 3: Added some precisions about other differences with the official binaries, and a small patch I somehow forgot.

There was no power again at the office today (thanks to my boss for sounding me while I was laying in bed so I had a pretty free day today. This is the first of my Unexpected Series of Events (although, in retrospect, this is somewhat expected since we did lose power at the office yesterday, giving credence to Clair’s story…) So I spent a little more time in bed, trying to get sleep; but my Mom got me ony my feet, calling via landline all the way from Daet, which just got its power restored a few days prior. She told me that my Tita Mendy will be arriving tomorrow, and she’ll be carrying some of my things too. That’s the second Unexpected. After that I left the house to deposit my second paycheck from work and payment for my second semester at school. A quick trek back home for lunch, and a few pages of Even Grues Get Full after, I went to Robinsons Place to check mail for free (well, not really free since I usually pay for my cup of Java to have a reason for taking a table.) As I’ve come to expect of freebies, free WiFi in Robinsons is rather limiting, as it appears to only allow HTTP ,S connections (yeah, no Yahoo! even for the unenlightened masses!) The bandwidth, in fairness, is fairly decent, allowing for a good audio or video stream to pass through without much lag (as long as its from HTTP ,S .) However, today’s service was extra crappy, as it appears that the WiFi DHCP server went down, and I couldn’t acquire an IP address. It wasn’t much of a problem for me, though: last weekend allowed me to spend a lot of my time hanging out in the place as it was the only place nearby to have seemingly continuous DC power (the storm that passed over pretty much knocked down normal AC power everywhere,) and also gave me an excuse to explore the WiFi network, letting me know such minutiae as the right IP address block and gateway Robinsons Free WiFi used. Hence, even without DHCP, I was able to configure Perlis to connect via a statically-randomly-chosen-by-magic-255-ball IP address. This wasn’t Unexpected. What was Unexpected was what happened next: as I was surfing the Web, I noticed that the other folks nearby were having difficulties accessing the free WiFi; of course, they didn’t have the information (that I had known by simply being observant) that they needed. Nearest to my table were a couple of Korean-looking foreigners and a doctor-looking guy inquiring each other if they were able to connect. I went near them and asked them about it too. Yeah, my deductions were correct; the foreigners (hello, Emma and Jay) were Korean students learning English, the guy (hello, Charlie Atienza) was a dentist, and all of them couldn’t connect to the Net. Windows was choking up on them, since it could not acquire an IP address. So, needless to say, I came to the rescue, and within a few minutes (which included trying to change the Korean’s locale settings to Engrish, which we eventually gave up, and forcing me to hibernate Kubuntu and booting to Windows just to find the right Network Settings menu, duh) I got them to have a working, albeit laggy, internet. I couldn’t get Charlie’s laptop working though, since it seemed to suffer another problem althogether :/ At any rate, meeting new people over this problem was by itself quite Unexpected, but that wasn’t the only thing: Charlie noticed my Kubuntu desktop earlier and recognized it immediately as open source. It turns out that Charlie have seen FOSS operating systems in action via Knoppix, and he knows Dr. Alvin Marcelo (of CHITS fame) and Eric Pareja, and is also quite involved in bioinformatics too. Small world indeed! =) I guess having no power at the office makes for a good adventure, after all. Well, yesterday was quite an adventure in itself (Clair can tell you all that, and more ) Today, however, was pretty much very Unexpected, and indeed I’m thankful that so many surprises come my way. The last Unexpected: I forgot to update my phone number on the calling cards I gave away today. Oh well…

After two years of using lkwiki, an old kwiki version that was extended to support full LaTeX documents to be managed and to store it's information in subversion, it is time for a rewrite. This week, I built the basic working foundation, in time for the new term at my University in Karlsruhe, but hopefully also for other people to use. So hereby, I announce:Latexki consists of two parts: The latexki binary, written in Haskell, is called by subversion after a commit and generates the static wiki pages (both text and LaTeX-based). It only updates what's needed (since running latex is expensive), but tracks dependencies like \input in LaTeX. The other, actually optional, part is a CGI script written in python which provides simple write-access to the subversion repository and which should handle conflicts with the same grace as subversion itself.Some, especially the planet.debian.org readers, will now immediatelly say that this is the same idea as Joey's ikiwiki and that I should just have extended his software. Now, I had the idea independently (after all, lkwiki works like this for two years now), and while ikiwiki is more a general purpose wiki, I wanted to create a tool specifically tailored for the collaborative management of LaTeX documents, the text pages are just side-play. Also, I wanted to to my own thing to use the subversion bindings to access the repository directly, without the need of a working copy, for the edits. It turned out that with pysvn, this is not possible, but at least I don't have to call the svn binary and using temporary directories for the working directory should be a clean solution.While the code is basically working, it still needs some testing. I'm also very eager to hear comments about the code itself, especially from a security point of view, but also from a "how to this nicer in haskell" point of view. You can find the code on the wiki itself, as all non-wiki, non-latex files are just wrapped in <pre> and put on their own page. Also, the TODO list is long. Patches are welcome, and if you want to use the software yourself, I'll help with any deployment problems.To the lkwiki users: I plan to switch the lkwiki repository to latexki before the semester starts. Some files will have to be renamed, and some detail code to be written. Feel free to test the latexki code to make sure we don't have problems then.

Last night, I worked a bit on the Debian package for darcs. darcs is an advanced revision control system, "two senses in which it is supposed to be advanced: 1) each copy of the source is a fully functional branch, and 2) underlying darcs is a consistent and powerful theory of patches.". Darcs is also written in Haskell, which makes it even more cool. When I did my first big group project in college, I started using CVS and completely loved it. I tried subversion for a while last year, and at home and work I'm currently using arch / tla. I'm excited about these two distributed revision control systems, tla and darcs. Keeping packages in VC: Since the author of darcs, David Roundy, is apparently a Debian user (and a skillful one at that), I expect this package to be a joy to take care of. At his suggestion, I'm going to keep my changes in darcs itself, and I figure that while I'm at it, I'll keep all my packages in darcs. I'm debating a bit about how to go about this, though. I could keep just the "debian" directory in version control, but then if I have to change the upstream sources (like the Makefile), then I couldn't track that. On the other hand, if I keep all the upstream sources in VC, then I'd have to sorta pound on the repository whenever there's a new release, with a bunch of big changes. Not too bad, I guess. What do those of you who keep packages in version control do? I was very pleased to see Colin's blog entry yesterday about Intel support of its Centrino chipset for Linux. I've been sending mail to them every couple of weeks for the last 8 months or so.

Yesterday, I uploaded libcommons-collection3-java to add the testframework jar (bug#268223). I investigate the security alert for tomcat5 (CVE2006-3835) as mentioned by Alec Berryman in bug#380361. Alec also filed this bug for tomcat5.5 but I was not able to reproduce the attack with the releases of tomcat in Debian. I filed a removal bug for libgnujaxp-java (bug#381014) which is in GNU-Classpath for a long time now. I uploaded a new upstream of libapache(2)-mod-jk (bug#338158). Today, I uploaded libmsv-xsdlib-java (the package was prepared by Eric Lavarde, but it was refused by ftpmasters because of the license) to non-free and solved the FTBFS of libjaxp1.3-java reported by Andreas Jochens (bug#379530). Except the security alert I closed because I think they were not affected releases of tomcat in Debian, I did not investigate more bugs of tomcat. But I’ll need it for my day-time and extra jobs so I hope I’ll be working on it after augustus 15. Update: I’m trying to fix argouml in Debian and that’s a huge job (well, the whole afternoon!)!

1. Update libtoolbar-java (new upstream + comment issue#6);
2. Update libswidgets-java (new upstream + comment issue#1);
3. Downgrade libgef-java to match ArgoUML development;
4. Update ArgoUML from 0.19.6 to 0.22.beta3 (new upstream + open issue#4391 and issue#4392). The main developer of ArgoUML said in the mailing list that this release will not be that much different to the final release and the new upstream upload (plus some corrections in the package) will permit to close some bugs: bug#342200, bug#217878, bug#335294, bug#353464, bug#368244, bug#289241.

Even with all this work, argouml does not want to start on my laptop. It’s a problem loading the ‘models’. I suspect a problem with the new mdr-model that I do not build because of dependencies not documented and not DFSG free. So I uploaded every package except argouml. I updated the subversion repository so the work is not lost and I’ll review the problem as soon as possible. You can find a copy of the generated package at my Debian’s webspace (click on the argouml directory).

Merc Molist interviewed me for El Pais, one of the biggest Spanish newspapers, which also happens to be my favourite one, in their weekly technology special, El CiberPais.

The interview, in Spanish, is here. Ugly pic of me wearing the Debian Women Tshirt in the printed version only.

I must say Merc made a great job out of a difficult subject, sexism in IT.

Update: Zobel provided me with a link to an Engrish version of it. Google 's Translation is not much better.

I've started looking at Trac recently, a nice web-based project management tool written in Python. It integrates with existing Subversion repositories; for example, you can browse the code in your repositories with Trac (it'll be displayed syntax-highlighted), view diffs between revisions etc. etc. Additionally, you get a wiki (e.g. for project documentation), as well as a built-in bug-tracker a la Bugzilla, all integrated nicely into a single piece of software... It's Free Software, of course (the license changed from GPL to revised BSD somewhat recently)... A few words on the installation:

• First, install Trac, e.g. via apt-get install trac.
• Then create a so-called Trac environment with trac-admin /path/to/environment/myproject initenv. You'll be asked where your svn repository resides, what's the name of the project etc.
• You can then edit /path/to/environment/myproject/conf/trac.ini, and change the header logo/URL, the default component/priority/issue-owner and more.
• For more administration, I recommend using the interactive Trac shell via trac-admin /path/to/environment/myproject. Type "help" for um... help.
• Read the docs for how to setup the web server in order to run Trac (you can use CGI, FastCGI, or mod_python).

So far I've set up ca. 7-8 Trac instances for various projects and I'm quite happy with it. While I was at it, I also created a tiny Trac article in the German Wikipedia. You can get tons of useful plugins and macros over at trac-hacks.org for additional functionality, e.g. DoxygenPlugin, GanttPlugin, DebianBtsMacro, and many more.

Hi! This is Comas, the conference management system we all know and love! Perhaps you remember me from /www.consol.org.mx/">/www.consol.org.mx/">CONSOL 2004 and 2005, Debconf 5 and 6, CICOL, Seminario Globalizaci n, Conocimiento y Desarrollo or other such great conferences! Well, it is a pleasure for me to announce I am moving.
That's right - My developers have felt too constrained by CVS to keep being merry and productive, and decided to move away from it and to Subversion. If you are tracking my development history, you should have noticed a new file in my base CVS directory, called DONT_USE_THIS_REPOSITORY_ANYMORE. I will reproduce it here following Gunnar's wishes, and hoping it is useful to you.

PLEASE DON'T USE THIS REPOSITORY ANYMORE! Just in the meantime, while we migrate our current installations to point to the correct server, while our users take note, and while the kind GBorg admins lock down this project: PLEASE DON'T USE THIS REPOSITORY. WE HAVE MOVED. The Comas project will no longer be hosted at GBorg - We are moving to Debian's Alioth.
Comas' webpage (although it is still ugly :) ) is still the same as always. The repository will no longer be handled through CVS - We switched to Subversion. Don't worry, the usage is basically the same. You can use anonymous access to get the Subversion tree. If you want to participate in the project, register at Alioth and ask us for commit access. You can also use the very nice SVN Web interface, which allows you to look at each of the files, view the changes, and even subscribe to the Comas RSS feeds! Development goes on. Stay tuned! Greetings, - Gunnar Wolf

Of course, as in any migration, there is still a lot of things to do. Mail the other contributors and interested people notifying them of the move. Migrate (and check the validity of) any tickets we have in the old site. Point all the places where there is Comas-related information to the new repository. Close the existing project page at GBorg. Sanely re-structure the repository in a more standard and functional way (and hope it does not break current installations ;-) ). Rework the documentation that has been neglected in the last months. Rework the bits of logic that never smelt very good but -as a dead rat- now positively stink. Fixe the things that will eventually stink as well... Anyway, I'm sure this will speed up my growth!
I am very excited on which way my dear authors will continue to push me - I know I'm quite a lousy program for many things, and I know there is a lot for me to learn until I am a military-grade conference management system - But my many parents have written me with deep love, and I understand they had to write hastily parts of my code. I understand their mistakes, but I hope they make them go away soon.